6-4 Client/Server Technologies
LAWRENCE K. COOPERm
ALLAN STEVENS
Although much of the client/server market focuses on the tools used in the implementation of client/server systems, it is equally important for managers of organizations that intend to implement client/server across the enterprise to understand the underlying technologies. There are currently two enabling technologies of client/server computing: Open Software Foundations Distributed Computing Environment (DCE) and Object Management Groups Object Management Architecture (OMA). This chapter explains both of these technologies and provides some insights into their current maturityinformation organizations should consider before implementing them. It also describes the support available for each technology from the mainstream hardware and software vendors.
DISTRIBUTED COMPUTING ENVIRONMENT
This section examines DCE and explains its features and support for the client/server model. The Open Software Foundation (OSF), prior to creating DCE, consulted extensively with software vendors to determine the key elements needed to build an underlying technology to support the client/server architecture. DCE provides the end user with transparent access to the benefits of its services; it is operating system independent and, at least theoretically, can conceivably be run on any hardware platform.
Equally significant, DCE is a layered architecture that easily permits systems designers to blend different software environments within the same client/server architecture. The purpose of network computing environments is to allow applications to be distributed among heterogeneous hardware and software platforms. As shown in Exhibit 6-4-1, DCE provides a framework of services for distributing applications.
Exhibit 6-4-1. Open Software Foundations DCE Model
One of the strengths of DCE is its flexibility. It is based on standard interfaces such as POSIX and X/Open. The layered architecture allows DCE to support both the Open Systems Interconnection (OSI) and Transmission Control Protocol/Internet Protocol (TCP/IP) stacks and to support new technologies as they become available. DCE provides two basic levels of service:
- Basic distributed services, which allow developers to build applications.
- Data sharing services, which provide distributed file systems, diskless system support,and microintegration.
Basic Distributed Services. DCE provides the following basic distributed services for developers:
- Remote procedure call (RPC).
- Distributed directory service (DDS), cell directory service (CDS), and global directory service (GDS).
- Security service.
- Threads.
- Distributed time service (DTS).
Data Sharing Services. DCE provides the following data sharing services for users:
- Distributed file systems or services (DFS).
- Diskless system support.
- Desktop support.
The threads, RPC, CDS, security, and DTS components are commonly referred to as the secure core and are the required components of any DCE installation. A DFS is an optional component. DCE also includes administrative tools to manage these components.
As a middleware or enabling technology, DCE is not intended to exist alone. It should be bundled into a vendors operating system or integrated into the operating system by a third-party vendor. For example, DCEs security and distributed file system can completely replace its current nonnetwork analogs.
As a de facto standard, most hardware and software vendors have committed to providing DCE on their platforms. These vendors include not only such OSF stalwarts as IBM, Digital Equipment Corp., and Hewlett-Packard Co., but also other key vendors such as Novell, Inc. In addition, a number of major user organizations (e.g., the European Economic Community) have embraced DCE as their standard for distributed applications.
DCE SUPPORT FOR CLIENT/SERVER
DCE is more than an application or a server software package. DCE components must be implemented between the applications and the network services on both the client and server platforms.
The interaction between the DEC components is transparent to end users. As shown in Exhibit 6-4-2, the client-side components of DCE must contain, at a minimum, the DEC fundamental services layers. The server must contain the DCE fundamental services and data sharing services. The following section provides an explanation of the major components of DCE.
Exhibit 6-4-2. DCE Integration of Applications and Network Services
DCE Remote Procedure Call Interface
The DCE RPC facility provides communication between software modules running on different systems in a simple and efficient manner. Similar to Sun Microsystems, transport-independent RPC (TIRPC), the client application calls functions that have been predefined by the server. The RPC features an easy-to-understand interface definitional language (IDL) that allows programmers to specify the operations exported by a server to clients. This definition of functions is called an interface.
An interface is a set of RPC operations and associated data. Every interface contains one or more operations. An operation is an actual remote procedures. Each operation may have input and output parameters associated with it, just like any procedure call. DCE RPCs provide the same behavior for applications regardless of the transport service used. Applications need not be rewritten for different transport services. Both connection-oriented and connectionless (Transmission Control Protocol and User Datagram Protocol) transports are supported.
A client can use as many different services as it needs or as many different interfaces as it has access to. A client can connect to multiple servers providing different services or multiple servers providing the same service. To keep track of the servers, the DCE RPC mechanism includes a context handle, which can be created by a server and returned to a client. This handle is used on subsequent RPCs to identify the client (see Exhibit 6-4-3).
Exhibit 6-4-3. DCE RPC Conceptual Model
|